Have you brought back the CRC to its original byte order?

No - I think I was looking at the wrong diff when I said it doesn't need to be changed, as I was working on 2 different computers.

With this patch, you should get data that matches what was discussed in #1826. If you don't let me know and I'll take another look.

I'm unable to setup my PlutoSDR to transmit valid M17 packets. For some reason the sample rate of the transmitted signal is much too high.

Why do you have BB set to that rather unusual value of 65104?

How are you determining that the sample rate is to fast?

65.104k happens to be the lowest value I can get. I think it is too fast because I can see a large part of the transmission in the SDR++'s demodulator window.

65.104k * 32 = 2083.33k (appears in the upper right) which is effectively the lowest sample rate you can obtain with the Pluto without using the FIR decimating filter (FIR button + decimation combo next). However I am not sure sample rate is the issue because the modulator should accommodate the required sample rate to the baseband sample rate with the rational interpolator. I suppose it needs at least 48k so anything higher than this is fine.

We need someone else than me to check this out, as I'm clueless what's going on.

65.104k happens to be the lowest value I can get. I think it is too fast because I can see a large part of the transmission in the SDR++'s demodulator window.

Just gave it a quick try here, SDRangel to SDRangel - and it doesn't appear to work in packet mode, if baseband sample rate is < 100k.

However, even using a sample rate > 100k, the m17 demod in SDR++ doesn't receive the packet.

If I look at a received signal using SDRangel's channel analyzer, the preamble is 40ms (as per the spec):

EoT may be a little short:

But the symbol rate looks OK. 8*1/4800=1.66ms

I have just recorded M17 stream sample, as obtained with the newest SDRangel. Looks like the preamble is ~550Hz tone, 170ms long, instead of 40ms of 2400Hz. Math looks correct too: 2400*(40/170)=565.

Edit: same problem when i use packet mode

Odd - because I don't see that. Can I suggest you try running your Pluto at a sample rate of 1MS/s.

2,083,336Sa/s is the lowest I can go.

Ok, use that, and I will too.

Please send a full screenshot of SDRangel

Streaming M17.

BTW - RFBW and Dev sliders should be removed, but that's another story :)

Ok, I see something odd. When I used the SRC callsign of SP5WWP, SDRangel stops displaying the packets (it's reporting a CRC error).

Can I suggest you duplicate the setup shown here:

As that's the packet we confirmed with the reference encoder, and I can see working here.

You can measure the packet transmission time, by pressing the pause button highlighted in red:

Then press the marker button in green and select Show All then Close.

The in the waterfall, hold shift, and left click at the start and end of the packet. It should presumably be 160ms as in the pic above.

Both B210 and PlutoSDR transmit too long frames and nothing is being decoded.

Both B210 and PlutoSDR transmit too long frames and nothing is being decoded.

I've no idea how that's possible, without me seeing the same.

Ok, I see something odd. When I used the SRC callsign of SP5WWP, SDRangel stops displaying the packets (it's reporting a CRC error).

This looks like a bug in M17DemodProcessor::decode_lsf()

if (!lsf[111]) // LSF type bit 0
{
    uint8_t packet_type = (lsf[109] << 1) | lsf[110];

It's using bit numbers as indexes in to a byte array. Can be fixed with:

if (!(lsf[13] & 1)) // LSF type bit 0
{
    uint8_t packet_type = (lsf[13] >> 1) & 0x3;

Was decode_lsf() originally located in the library you use? Is the bug coming from the lib itself?

Was decode_lsf() originally located in the library you use? Is the bug coming from the lib itself?

Doesn't look like it.

Both B210 and PlutoSDR transmit too long frames and nothing is being decoded.

Can you measure the time in the TX spectrum, rather than the RX spectrum., please? All I can think of, is for some reason (E..g PC/USB not fast enough), the samples aren't being output at the correct rate, unless there's an uninitialised variable somewhere..

BTW - RFBW and Dev sliders should be removed, but that's another story :)

I can only receive audio stream in SDR++ if I increase the SDRangel Dev setting above 5.7k (default is 5k). The closest match to the SDR++ reference lines is at 8k.

I still can't receive packets though in SDR++ though.

Both B210 and PlutoSDR transmit too long frames and nothing is being decoded.

Can you measure the time in the TX spectrum, rather than the RX spectrum., please? All I can think of, is for some reason (E..g PC/USB not fast enough), the samples aren't being output at the correct rate, unless there's an uninitialised variable somewhere..

Same issue. TX time is longer than vertical range.

If you increase the FFT size, you should be able to increase the vertical range. But seems too long anyway.

Yep. I doubt this has anything to do with USB, as the RX rate matches TX and still works.

BTW - RFBW and Dev sliders should be removed, but that's another story :)

I can only receive audio stream in SDR++ if I increase the SDRangel Dev setting above 5.7k (default is 5k). The closest match to the SDR++ reference lines is at 8k.

So, from the M17 specification, FM peak deviation should be 2.4k, but SDRangel currently has a default setting of 5k.

However, setting the symbol output to constant 1, a setting of 5k doesn't actually result in a deviation of 5kHz.

The problem is in M17ModSource::modulateSample(). Currently, we have:

m_modPhasor += (m_settings.m_fmDeviation / (float) m_audioSampleRate) * t1;

Where m_fmDeviation is 10,000 if GUI setting is 5k. (i.e. full deviation)

However, I think we actually want 2 * pi * peak deviation, so:

m_modPhasor += ((2.0f * M_PI * (m_settings.m_fmDeviation / 2.0f)) / (float) m_audioSampleRate) * t1;

And with that, I then see a deviation of 2.4kHz with GUI setting of 2.4kHz - and audio is correctly received in SDR++.

On the SDRangel receive side, I think a factor of PI is missing in the demod too:

    m_phaseDiscri.setFMScaling(48000.0f / (2.0f*settings.m_fmDeviation));

Should be:

    m_phaseDiscri.setFMScaling(48000.0f / (2.0f*M_PI*settings.m_fmDeviation));

And then the constellation fits in to the box with a GUI setting of 2.4k.

FM peak deviation should be 2.4k, but SDRangel currently has a default setting of 5k

Actually, the peak instantaneous deviation is somewhat larger than 2.4kHz, as the baseband is RRC filtered and exhibits a small overshoot. But yes, of course +3 symbol should give +2.4k deviation. Otherwise, your maths makes much sense, well spotted. Can the sliders be removed to avoid confusion and misuse? I think we are going to fix a few bugs along the way, hehe :)

Actually, the peak instantaneous deviation is somewhat larger than 2.4kHz, as the baseband is RRC filtered and exhibits a small overshoot. But yes, of course +3 symbol should give +2.4k deviation.

Yep.

This is the t1 signal in the above equation:

I checked a value of 1 results in a deviation of 2.4kHz, and >1 will give that overshoot.